In many secure communication applications, a seed is required in order to perform certain cryptographic operations such as encryption, decryption, authentication, etc. The seed may comprise, by way of example, a symmetric key or other secret shared by two or more entities.
One such application is in authentication tokens, such as the RSA SECURID® authentication token commercially available from RSA Security Inc. of Bedford, Mass., U.S.A. The RSA SECURID® authentication token is used to provide two-factor authentication. Authorized users are issued individually-registered tokens that generate single-use token codes, which change based on a time code algorithm. For example, a different token code may be generated every 60 seconds. In a given two-factor authentication session, the user is required to enter a personal identification number (PIN) plus the current token code from his or her authentication token. This information is supplied to an authentication entity. The authentication entity may be a server or other processing device equipped with RSA ACE/SERVER® software, available from RSA Security Inc. The PIN and current token code may be transmitted to the authentication entity via an encryption agent equipped with RSA ACE/AGENT® software, also available from RSA Security Inc. If the PIN and current token code are determined to be valid, the user is granted access appropriate to his or her authorization level. Thus, the token codes are like temporary passwords that cannot be guessed by an attacker, with other than a negligible probability.
A given RSA SECURID® token typically contains one or more seeds that are utilized in computing the token outputs. The authentication entity performing the verification of the token outputs requires access to one or more seeds associated with the token in question. Typically, such authentication entities have access to the same seed or set of seeds that the token uses to generate its output.
In certain situations it is desirable for the token and authentication entity to be configured to generate a seed for their joint use. Conventional seed generation techniques can be problematic in that use of such techniques may result in the seed becoming accessible in plaintext form to entities other than the token and the authentication entity. This problem may be addressed by requiring the token and the authentication entity to be pre-configured with certain trusted keys. However, such an approach is inefficient and may introduce additional security concerns.
Accordingly, a need exists for improved techniques for secure seed generation in authentication tokens and other applications.